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ABSTRACT 


The need for a project information and control system at 
FNOC was examined. Personal interviews and checklists were 
used to determine user requirements. Several manual and 
automated alternatives were presented. The author concluded 
that the purchase of a software package, would in all prob- 
ability, be the most efficient and effective alternative. 
Several packages were evaluated and 3 packages were finally 


presented for more extensive review by FNOC staff. 
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PREFACE 


Throughout this thesis the reader will find three cate- 
gories of statements. Scientific facts are those statements 
that are supported by scientific research in the field. 
These statements can be identified by a direct reference. 
Authors opinions are specifically identified as such. All 
other statements can be classified as General management 
lore. This type of statement refers to generally accepted 
theory in the management field; however it is unsupported by 


scientic research. 





I. INTRODUCTION 


In an environment characterized by increased numbers of 
projects, drastic increases in demands for information, and 
strong limitations on personnel, computer, and financial 
resources, Fleet Numerical Oceanographic Central (FNOC), 
must look at alternative courses of action to maintain an 
effective level of performance in project management. 

It is the intent of the author to examine the need and 
information requirements for, project information and con- 
trol system (PICS) at FPNOC. This system should not only pro- 
vide for the flow of pertinent project information to top 
Management; but also assist the project manager and other 
middle managers in estimating, assignment, and scheduling of 
project tasks and resources. Alternative courses of action 
will be identified and available software packages examined, 
to determine their capability of meeting those requirements. 

This document will provide to FNOC management assistance 
in selecting the appropriate course of action as well as 
providing a preliminary analysis of user reguirements. 

Prior to examination of FNOC's project management needs, 


a review of the literature relevant to project management 





will be provided. Specifically, there will be an examination 
of several of the problems associated with software project 
Management. An awareness of these problems will assist the 
project manager in visualizing the importance of effective 


project control. 
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II. REVIEW OF PROBLEMS IN SOFTWARE PROJECT MANAGEMENT 


An increasing percentage of DOD monies are allocated for 
direct software acquisition or embedded software. In 1977, 
the United States government estimated the cost of software 
development, testing, and maintenance to be about $4 billion 
per year. At that time the government owned approximately 
$25 billion worth of currently used software. [Ref. 1] 
Overruns of 100% in both cost and delivery time have not 
been uncommon occurrences in software projects; and in fact, 
there have been cases of total failure to develop systems. 

There has been a great deal of attention and speculation 
as to the cause of these problems. It is the author's con- 
tention that effective project management on the part of the 
contracting project manager can minimize and perhaps elini- 
nate most of these problem areas. 

A review of the literature surfaced several problem 
areas in software project management. These problems are 
presented here, together with information for the project 
Manager who desires to minimize the risk of project failure. 


Certainly the awareness alone, of potential problems, 
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will increase the effectiveness of the project manager, and 
provide direction toward project success. 


PROBLEM: 


Poor accountability and control structure, such as: 
* inappropriate measures of effectiveness 
* minimizing development costs and schedule 


* emphasis on percent coded 


== ee: ee ame eee a 6) Ee ies me, Me 


| 


The first method of control starts with the organiza- 
tional structure. Usually the project organization is set 
up to meet a specific objective and it dissolves after it 
has been accomplished. This, in itself can create a problen. 
The manager may not be fully aware of the skills of the pro- 
gramming teams. The host organization must therefore strive 
to maintain accurate documentation as to those abilities. 

Managers must also decide on a mangement system. There 
are many automated management control systems available to 
assist a project manager; however, it should be remembered 
that they must fit the organization, and that simply because 
they have been used with great success by others , does not 


guarantee their success in all structures or projects. This 
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1S a point that many managers fail to take into account when 
they are looking for that magic control method. [In matching 
a method to the organization the manager must take into 
account such things as whether or not project management is 
linear or matrix oriented, what item the organization is 
most interested in tracking, and what levels of reporting 
are required. 

Establishment of a project control room to centralize 
information needed by the project team might prove to be of 
value to the organization. Some of these items include: 
documentation, master schedules, status reports, change 
authorizations, budget, systems flow charts, edit rules, and 
user tralning information. Consideration might also be 
given to the establishment of a project control secretary 
position. 

Emphasis on percent coded tends to get people coding too 
early and key activities such as requirements and design 
validation, test planning and draft of user documents are 
neglected. It is also true that percent coded is not indica- 
tive of where the project is relative to the schedule. It is 
extremely subjective. To combat this problem, key milestones 
Should be set. These must be measurable milestones. For 


example, milestone 1 might be acceptance/approval of design 
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criteria by the user. Involvement of the user early in the 
project and throughout its existence will help to keep the 
project on track and hopefully surface user problems early 
in the project. 

Structured programming techniques; specifically top-down 
design, provides a procedure for organizing and developing 
the control structure of a program in a way which focuses 
attention early to the critical issues of integration and 


interface identification and definition. 


PROBLEM: 
Software requirements specifications 
(1f they exist) 


are often ambiguous. 


Le a eee] 


— 


These requirements must be written by personnel knowled- 
gable in both the systems requirements and software develop- 
ment. This is often not the case, especially where embedded 
software is involved. 

Technology can be of assistance here. Machine analyzable 
software requirements systems are available. The pioneer in 
this technology was ISDOS, developed by Teichroew at the 


University of Michigan {Ref. 2]. although it was developed 
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primarily for business systems applications; the United 
States Air Porce is currently using and sponsoring exten- 
sions to ISDOS under the computer aided requirements analy- 
Sis (CARA) program. Another even more extensive and powerful 
system is one developed under the software requirements 
engineering program (SREP) by TRW for the United States Army 
Ballistic Missile Defense Advanced Technology Center. Even 
these automated systems have limitations however; the capa- 
bilities to represent large file processing and man-machine 
interactions are limited. They are a start however. 

Often a project manager will inherit a project which is 
not adequately defined. Realizing this and taking immediate 
steps to remedy the problem is necessary to project success. 
The extra time spent at this point will pay off in the end. 
Because of the nature of software development, errors 
d2tected early in the cycle are less costly then those dis- 
covered in later phases, Figure 1 {[ Ref. 3]. A project man- 
ager must avoid the temptation to allow detailed design and 
coding to begin prior to establishment of user requirementts 
and an overall plan. The extra time spent in the definition 
and design phase will be time well spent if it minimizes the 


likelihood of problems in later phases. 
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PROBLEM: 
Software testing and reliability activities are 
| often not considered until the code has been 


tun for the first time and found not to work. 


’ 


one 


In general the cost of testing, 40%-50% of the devlop- 
ment effort, is due to the high cost of reworking the code 
at this late phase of the cycle [Ref. 4]. There is a great 
deal of wasted effort resulting from the lack of an advanced 
test plan to efficiently and effectively guide testing 
activities. 

The development people must consider the testability of 
their design and ensure that code can be exhaustively tested 
before the next higher level of code is added. Early loca- 
tion and correction of errors results in much more reliable 
programs. A solid test plan should provide for an indepen- 
dent validation team to be established at the beginning of 
ime, project. 

The consequences of undetected errors can range fron 
Minor to disastrous. A well known example of the latter was 
the Mariner 1 interplanetary probe. The absence of one bar 


over a letter in a computational equation resulted ina 
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unrecoverable problem, left no alternative but to destruct 
the $18.5 million dollar rocket shortly after launch. [Ref. 5] 
Reliability can be eden een by imposing standards on 
programming style for all code written. Structured progran- 
Ming has a lot to contibute in this area. Structured pro- 
gramming involves dividing a complex program into 
progressively smaller modules, each of which has a well 
defined task. The most refined modules are small and logi- 
cally straight forward. They have limited control structures 
and one entry and exit point. The conciseness of the modules 
allows the programmer to use formal mathematics to prove the 


correctness of the code. 


eS) 
| PROBLEM: | 
| Cost estimates in software projects are often | 
| incomplete and grossly inaccurate. 
There is always the element of risk, especially on 
projects that push the state of the art. Estimating hardware 
costs has followed established methods, software on the 


other hand, is seldom handed to a software estimating group. 


In fact, software estimating seldom follows any scientific 
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procedures, with perhaps the exception of those 
Organizations utilizing PERT/CPM*. 

The DOD is currently evaluating macro and micro techni- 
ques for estimating resources required for ADP projects. The 
macro technique provides an overall lump sum estimate of 
manpower and costing factors for the entire systems life 
cycle. The micro technique provides detailed manpower and 
costing for each phase of the life cycle {Ref. 6]. 

Studies by industry have concluded that there are no 
Simple universal rules for costing software accurately and 
that to estimate it accurately it is neccesssary to under- 
Stand the nature of the individual program {Ref. 7]. 

It would appear that, the problem with software cost 
estimates is that until we have more standardization of 
procedures in the software industry, the estimates will con- 
tinue to be grossly inaccurate due in part to the varying 
programming methods. 

One pitfall to avoid in worrying about software costs is 
that of concentrating too much on reducing software develop- 
ment costs. What really needs to be reduced is software life 


cycle costs. Instead, we too often find project Managers 


| a a — Atl Tati DF es 


* FOr Geis, gist information on PERT/CPM see Cleland,D.L. 


and pene Systems Analysis And Project Management, 
McGraw- viii 68, chapter Te 
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making a lot of trade-offs during the software development 
to meet schedule and cost constraints. Many of those trade- 
offs trade maintainability for speed of development. 

In a discussion during the 1973 Symposium on the High 
Cost of Software, it was pointed out that the avionics soft- 
ware in the Air Force cost something like $75 per instruc- 
tion to develop; however, the maintenance* of the software 
had costs up to $4000 per instruction [Ref. 8]. 

The trend projected through 1985 is for software costs 
t2 continue to rise (Ref. 9]. In part, this is due to an 
increase in size and complexity of projects and an overall 
increase in the rate of technological change. The industry 
is currently pouring R&D money into exploration of auto- 
mated methods. Some progress has been made in this area; 
however in the author's opinion, it will be some time before 


wide spread use. 


PROBLEM: 


Schedule slippage 


“oe 


Maintenance includes all costs after the initial devel- 
opment effort associated with keeping the software in opera- 
tion (including revisions/upgrades). 
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Schedule slippage results for a number of reasons. Nota- 
ble among them is personnel related problems. Skill levels 
among programmers vary greatly, also the amount of time nec- 
cessary to program in different languages varies. These fac- 
tors together with the degree of complexity of the systen 
required, must be considered by the project manager in mak- 
ing the schedule estimate. Most often a project manager 
inherits a project for which these estimates have been made 
prior to the assignment of the project team and the project 
manager will have to make adjustments and recommednations to 
deal with inappropriate estimates. 

Project managers must rid themselves of the idea that if 
they get behind schedule, adding more programming staff will 
solve their problem. In the contrary, in many instances it 
Will no doubt have quite the opposite affect That is, the 
new staff will have to be brought up to speed and this 
entails pulling experienced programmers off the job for this 
purpose, resulting in even greater delays. Brooks! Law 
states: "Adding manpower to a late software project makes it 


later " (Ref. 10]. 


It is obvious that the preceding problems are not inde- 
pendent, and that difficulty in any one of them has a signi- 


ficant impact on each of the others. 
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In summary, the difference between software project 
successes and failures has most often been traced to good or 
poor .practices in software management. These problems can 
be divided into the following three major areas: 

POOR PLANNING: Generally this leads to large amounts of 
wasted effort and idle time because of tasks being unne- 
ceassarily performed, overdone, poorly synchronized, or 
poorly interfaced. 

POOR CONTROL: A plan is useless when it is not kept up to 
date and used to manage the project. Also, the selection 
of the correct control method for the organization is cri- 
tical for success. 

POOR RESOUBCE ESTIMATIONS Without a firm idea of how much 
time and effort a task should take, the manager is ina 
poor position to exercise control. Improper assignment of 
personnel to tasks can cause cost and schedule overruns. 

In short, the key to project success lies with the man- 
agement team and the efforts they make to establish project 
control. In the following chapters, the author will examine 
FNOC*'s project management needs in relation to these and 


other considerations. 


fags 





Pits OVGRWEEW OF FNOC OPERATIONS 





FNOC provides a wide spectrum of numerical , neterologi- 
cal, and oceanographic products to worldwide users ona 
real-time basis. A multi-mainfrane computer center is used 
t> execute report processing, analysis, prediction, display 
and research jobs as a major part of the command's mission. 
A standard sequence of scheduled jobs known as the opera- 
tional run (OPS RUN) is processed every 12 hours to accon- 
plish a complete global meterological and oceanographic 
analysis and prognosis cycle. A database of current environ- 
mental observations and a complete set of climatological 
information is used. The goal of the OPS RUN being to pro- 
vide analysis and forecast fields and data for transmission 
to DOD facilities and users as soon as possible after the 
receipt of a observations. 

PNOC is an integral part of the naval oceanographic and 
meterological support system. See Figure 2. Environmental, 
meterological, oceanographic observations (raw data) and 
requests for services come into FNOC, the primary production 
facility, via the Automated Weather Network (AWN), AUTODIN, 


AMSAT, or the Suitland data line. The raw data is quality 
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checked, sorted, and edited by computer programs, after 
which the analysis, prognosis, and applications programs are 
run and the output processed and placed in the integrated 
database. 

A sophisticated series of prediction programs generate 
forecast variables such as wind, temperature, pressure, 
moisture, and sea heights, to provide the fleet with a four 
dimensional measure of the air-ocean environment in which 
they operate. These products are distributed to the four 
weather centrals (Pearl,Guam Norfolk, and Rota) via the 
Naval Environmental Data Network (NEDN) and the Naval Envi- 
ronmental Display System (NEDS). The weather centrals tailor 
these products before disseminating them to end users. In 
some cases FNOC provides environmental products directly to 
the end users. 

The products produced by FNOC are of two basic types; 
routine/ scheduled or tailored. Special reguests for tai- 
lored products are based on changing fleet or other opera- 
tional committments. These products are transmitted via the 
telecommunications system. Figure 3 is a listing of some of 
the products currently provided by FNOC. A primary emphasis 
in oceanoaqraphic modeling is support of antisubmarine war- 


fare forces. FNOC provides fleet units with expected 


24 





detection ranges for each of their acoustic sensor systems, 
nO matter where they are. Currently, satelite processing is 
becoming the focus of attention, as a means of providing a 
more accurate database. 

To provide all these services; FNOC maintains twenty- 
four hour computer center operations, manned by military 
and civilian personnel. There is considerable development of 
advanced techniques and capabilities in data processing, 
ocean and atmospheric analysis, prediction, display, appli- 
cations and communications. There is continual planning and 
lmplementation of computer systems upgrades. 

The project approach is frequently used to meet new and 
Changing requirements at FNOC; hence, there is a sound rea- 
son for seeking to optimize the project management proce- 


dures and controls. 
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FNOC PRODUCTS 
ROUTINE 


area forecasts 

Wind and sea warnings 
terminal and local forecasts 
oceanographic outlooks 
acoustic predictions 


analysis and prognosis for atmosphere and ocean 
TAILORED 


Optimum track ship routes (OTSR) 
enroute ship weather forecasts (WEAX) 
refractive effects 

ballistic wind and densities 
amphibious forecasts 

environmental briefings 
climatological studies 

optimum path aircraft routing (OPARS) 
acoustic predictions 

search and rescue (SAR) 
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Figure 3 
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IV. NATURE OF THE PROBLEM 


A. PAST HANDLING OF PROJECTS 

In late 1976 FNOC adopted a computerized descriptive 
list of projects. This listing was originally developed for 
use exclusively by the Data Integration Department. This 
action constituted the first step in the development of a 
MIS to assist in project control. This list was only a 
beginning and fell far short of fullfilling the needs of the 
command. Due to other commitments and limited resources, 
little progress was made in improving the system. There 
were several serious problems with the system; the report 
format was not well defined, file updates were irregular and 
incomplete, and milestone dates were passed without comment 
or explanation. A serious problem worth discussing, was the 
fact that the system lacked middle management support. The 
primary reasons given for dissatisfaction with this MIS 
were that it was a cumbersome and ill-defined system and 
that it provided very little, if any, benefits to the middle 
manager. 

The MIS received considerable command attention between 


1976 and 1977; however, commitment of personnel resources to 
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solve its many problems was lacking. After this period the 
MIS received only ocasional command level emphasis and by 
mid 1979 there was considerably less insistence on keeping 
the information updated. By 1980 the commanding officer had 
taken the MIS out of operation completely. 

It would seem that, by all development standards, this 
MIS was doomed from the start. Installing an information 
system is 4a complex job. It involves an examination of the 
entire structure of the organization and the information 
flow. Clearly, this was not done in this case. The need 
exists for more planning and some definite attention to the 


Organizational problems. 


B. CURRENT HANDLING OF PROJECTS 

Currently there is no automated MIS, neither are there 
any well-defined procedures for project control and 
maporting. 

Several manual r2porting/tracking mechanisms have been 
tried recently, including the completion of the form in 
Figure 4&4 These represent major milestones/tasks to be 
accomplished during the periods indicated. These tasks are 
listed by department, staff position, and major projects. 
Although only a crude mechanism; it does force involved per- 


sonnel to give some thought to their own priorities in 
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relation to the command's prioritieS. The problem is, all 
personnel involved do not contribute; therefore the informa- 
tion is not complete. 

A second mechanism currently in use is the Projects and 
Plans Summary, Figure 5, initiated during the spring of 
1981. The Plans and Programs Officer has identified 8 gen- 
eral project areas based on function; within these areas 
there may be many projects. This summary identifies primary 
resources involved and scheduled events, activities, and 
milestones for the current fiscal year and beyond. It is 
Strictly a manual effort and the initial summary took three 
days of concentrated effort to produce (this time does not 
include its planning time). These dates are monitored using 
Seriet Ly Peres) métnods which requires constant vigilance 
and attention to detail. It is highly likely that when the 
current Plans and Programs Officer leaves FNOC (in the fall 
of 1981) this summary will cease to exist. 

Reporting of development projects is handled via the 
Work Unit Package which is submitted twice a year and 
updated only for major changes. This report is produced on 
a word processor; however no data manipulation is done. 


This is due in part to references 24 and 25, which 
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specifically prohibit use of word processing equipment for 


data manipulation without prior approval. 


C. FNOC PROJECT ENVIRONMENT 

FNOC utilizes a matrix organization for project manage- 
ment. Figure 6 represents the general structure of this 
Organization, while Figure 7 depicts FNOC's operational 
organization. Matrix management is based on the concept of 
pulling together technical and managerial talent into a tean 
to operate without the limits of discipline or organiza- 
tional lines. Matrix relationships are far more complex 
than traditional functional relationships in which the rela- 
tionships are predominantly vertical with few, if any, 
cross-functional aspects. Each major group or department is 
primarily concerned with its own goals. The matrix organiza- 
tion changes these traditional patterns by creating new ver- 
tical, horizontal, and diagonal relationships among its 
members. Communication becomes far more critical in a 
matrix organization; thus, tight project control and 
reporting becomes increasingly crucial. 

The department head's goal orientation must also change 
due to the matrix organization, in that they must be con- 
cerned with project goals in addition to their functional 


goals. [Ref. 11] In a matrix organization, the functional 
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specialist is placed in the difficult situation of taking 
direction from two managers; therefore, if there are not 
well defined channels of authority, there is potential for 
considerable conflict. Irregardless of this, due to the 
nature of the project environment, matrix management appears 
to be the proper choice. The built-in conflict, if handled 
properly, tends to enhance initiative among the participants 
as they compete for the limited resources. 

Matrix management is indeed difficult; however, it faci- 
litates the coordination and integration of many project 
activities, and provides the flexibility required in a con- 
plex multifunction environment such as FNOC.* 

Two staff positions were established to aid in project 
planning and control. The PLans and Programs Officer, res-~ 
ponsible primarily for long range planning and budgeting, 
and the Development Coordinator, responsible for coordinat- 


ing R&D activities under work unit funding. 





*Por additional reading on matrix management consult 
reference 11. 
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V. METHODOLOGY 


This study focused on the identification of user 


reguirements for PICS. 


Reet DENTIFICATION OF THE PROBLEM 

The initial concentration of this thesis was to formu- 
late and describe a problem statement for project manage- 
ment at FNOC. Further discussion then focused on the 
various causes that had combined to produce the problem. The 
discussion also presented details about the past and current 
project management procedures . Having made a largely sub- 
jective determination of the problem, the next step 


involved an analysis of the user's needs. 


B. ANALYSIS OF USER'S NEEDS 

Twelve key FNOC personnel were selected on the basis of 
their senior management positions at FNOC or their expertise 
and longevity in the project management environment. Indivi- 


dual PERSONAL INTERVIEWS were conducted with each of the 





tweleve individuals. The question posed was; what informa- 
tion requirements and/or capabilities would you like to see 
in a project management and control system at FNOC (either 


automated or manual). Individuals responses were not 
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revealed to other interviewees and the interviewer limited 
her input, so as not to impose her views on those being 
interviewed. 

Responses from interviews were consolidated in an uned- 
ited CHECKLIST form and distributed to all FNOC personnel 
directly involved in project management at some level. Those 
involved in the personal interviews were also asked to con- 
plete the checklist inorder to validate the information and 
assure that the interviewer's interpretation of their origi- 


nal responses was correct. 


C. ANALYSIS OF REQUIREMENTS 

Check list responses were classified as to management 
level (CO/XO/ DEPT HEAD/PRINCIPAL INVESTIGATOR/PROJECT 
MANAGER) and analized. Items that were not felt to be 
necessary were deleted and a comprehensive list of require- 
ments was identified as the minimum necessary for a Project 


Information and Control System (PICS). 


D. REVIEW OF SOFTWARE PACKAGES 

The criteria to be satisfied by a project managment 
software package was outlined and a survey of available 
software packages was made. Each software package was 
compared to the established criteria to select the most 


appropriate package/packages. 
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This preliminary screening was based on the established 
general system requirements. The intention was to reduce the 
number of packages being considered to those that appeared 


most likeley to meet the needs of the organization. 


E. PRESENTATION OF ALTERNATIVES 

A variety of feasible alteratives were identified in an 
attempt to cover the entire spectrum of possibilities. 
Their advantages and disadvantages were examined and dis- 


cussed to give the executive a view of their relative value. 


39 





Vi. REQUIREMENTS 


A. OBJECTIVES OF THE PROJECT INFORMATION AND CONTROL SYSTEM 

The overriding objective of most organizations in imple- 
menting an automated information system, is to increase the 
overall effectiveness of the organization involved. In the 
private sector, this translates into increased profits. [In 
the public sector, it is not as easily measured. 

In order to define more specific objectives for the 
automated system, the author conducted personnel interviews 
With FNODS personnel. These interviews, together with the 
author's personal experience, were then used to describe the 
following overall objectives for an automated project man- 
agement and control systen. 

1. Must require minimal inputs to the system, that is, 
once the initial system has been established, it should be 
no more cumbersome to maintain then current record 
keeping. 

2. Must deliver information to the appropriate manager 
when it is needed, so that situations requiring immediate 
decisions can be controlled, and situations that are not 
pressing can be deffered, but not to the point of loss of 


eontrol. 
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3. Must provide for simultaneous horizontal and vertical 
dissemination of necessary information, so that top level 
management and every operating department, will be ade- 
quately informed. In particular, it is important that the 
vertical dissemination of information follow only the 
necessary path. Furthermore, information sent in a ver- 
tical direction should be directed only as low/high as 
required to make or retract a decision. 

4. Must reduce reams of information to meaningful facts 
for management to use in planning the future operations of 


the organization. 


B. USER INFORMATION REQUIREMENTS 

One of the first steps in developing or obtaining a 
software system, is to define the user's requirements. This 
is far more involved than it sounds. After almost twenty 
years of attention, it is still often the case, that compu- 
ter based application systems are developed behind schedule, 
over cost, dontt do as much as promised, and don't satisfy 
the user needs. At the heart of this problem, is the fact 
that, often the requirements for these applications were 
never stated accurately or completely in the first place. 


The fact that one may never reach perfection in this area 
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should not prevent an all out effort to identify require- 
ments as completely as possible. 

The importance to project success of getting these 
requirements right, can not be over stated. If the require- 
ments are not complete or correct, the system may not be 
usable. If the system is salvagable, the cost incurred in 
correcting the system may be excessive and the additional 
time reguired, could be time better spent elsewhere. There 
is also the possibility that the organizational effective- 
ness will be decreased, due to either not having a workable 
system, or having one that only partially meets their needs. 

Certainly our record of customer satisfaction is not 
good. For that reason, we must be aware of the problems and 
recognize that a substantial number of errors will exist in 
most requirements statements, unless specific action is 
taken to identify and remove them [Ref. 12]. 

There are three basic approaches to information require- 
ments analysis [Ref. 13]. 

DIRECT ANALYSIS, which involves interaction with the user 
to identify decision processes and information elements. 
INDIRECT ANALYSIS is the evaluation of data utilization, 
such as observing people or reports, in order to infer 


information requirements. 
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HYBRID ANALYSIS, which is a combination of direct and 
nda rest. 

The author utilized the hybrid analysis approach, 
together with her personal experience. It must be emphasized 
however; that this 1s simply a preliminary analysis of user 
requirements, and that a more extensive analysis should be 
undertaken if the decision is made to pursue this idea 
further. 

Information for data items was collected from inter- 
views, check list responses, and the author's experience. [It 
was not felt necessary to include every data item from each 
source of information. The amount of effort needed to obtain 
and enter some items of data, coupled with the increased 
Storage, capacity necessary, and subsequent longer retrieval 
times, far overshadowed the possible benefit that could be 
gained from having that information on line. 

The author's value judgements were used to define a con- 
prehensive requirements list that would be useful without 
being overly demanding on resources. Future evaluations of 
update and usage rates of these data items should be made 
once a system is in use, to reduce the size of the database 


by eliminating unused items. 
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The following are deemed minimal information 
reguirements for an automated project management and control 


systen. 


* A means of establishing and tracking milestones, actual 
versus planned. 


* A method_to provide information on available resources, 
personnel, monetary, and computer, and their utilization 
and/or allocation. 


* A means of indicating priority of projects. 


* A means of Soe soe promulgating lines of 
authority and responsibility. 


* The ability to include narrative comments. 
* A means of indicating time/scheduling information. 


* A means to break the project up into tasks and subtasks 
for tracking and reporting 


Reference 14 and appendix A , contain more detailed 
requirements for recommended data elements. 

It is recognized that these requirements differ with 
each level of management as does the degree of detail of the 
mieoumation. Anthony, [Ref.15] in his framework for plan~ 
ning and control, focuses on three categories of decisions 
which can be translated to the levels of project management 
at FNOC. [They ares 

STRATEGIC PLANNING: which is equivalent to the type of 


decisions made at the staff level (CO,X0O,staff 


_. *CRAS (Computer Resources Accounting System) will pro- 
vide information related to EDP usage. 
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assistants). They require only summary level information 
rather than more detailed reports. 

MANAGERIAL CONTROL: the key concern here is that 
resources are obtained and used effectively and effi- 
ciently to accomplish the defined objectives. In FNOC's 
project environment this can be equated to the principal 
investigator and department head. They require details of 
resource utilization and milestone information. 
OPERATIONAL CONTROL: at this level of decision the empha- 
Sis is on assuring that tasks are carried out effectively 
and efficiently. This equates to the project manager 
levei at FNOC. The project manager is concerned with the 
day to day operations. 

In order to provide the flexibility necessary to nest 
the diverse needs of the various users, this information 
should be accessable according to a number of retrieval 
criteria, such as: 


mMiletones exceeded 

upcomming milestones 

funding source 

responsible principle investigator,department,division 
name of project manager 

system relationship (ie. PEPSU, CCS,NEDS) 

priority 

estimated cost 


%* + + + &£ & & & F 


duration of projects 
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* classification of projects (ie. development, operational, 
Or maintenance) 


resource allocation exceeded 
* noncompliance with established update schedule. 


C. GENERAL SYSTEMS CAPABILITIES 

Aside from the information requirements listed in the 
previous section, there are a number of desirable capabili- 
ties the system should have. They include the following, 


which are listed according to relative importance: 


x Bagot Ty to run on eguipment currently available to 


* Easy/fast_update procedures, requiring little or no 
additional effort on the part of project staff. 


* At least 3 levels of eee summary, detailed and 
exception. To assure that only that _intormation of 
interest to a particular pened] Rens level may be pre- 
sented. Ackoff, {[Ref. 16] emphasizes that Cone ee 2° 
popular belief, managers suffer most from information 
overload rather than lack of information. 


* A means to control who is authorized to update/modify 
project information in the file. 


* Backup/recovery procedures 


* Plexibility in report formats to allow individual manag- 
ers to get the information they require in a form that 
is most usefull to them, It 1S critical that middle 

.Managers receive some direct tangible benefit from the 
project management and control system if they are to 
Support it. 


eMopecitic definitions (ie. cents ene 
task,milestione) so that all reporting is done in 
regards to a common basis. 

* Interactive capability option 


* ee to support multiple users in the interactive 
mode. 
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VII. SOFTWARE PACKAGE REVIEW 


Commercially available software packages are becoming a 
major market factor in the data processing industry. They 
have many advantages over independently developed applica- 
tions. Most packages are well designed and documented and if 
the package has been on the market for some time, there is a 
good chance that most of the serious bugs have been elini- 
hated. Software packages permit the installation of a new 
System for relatively less cost than that of in-house devel- 
opment due to the fact that the cost can be spread over many 
customers. There is little or no risk of cost or schedule 
overrun usually associated with software development 
efforts. This allows management to establish dependable 
schedules for implementation and accurate budget plans. 

The purchase of a software package also allows the 
organization to utilize the professional talents of their 
programmers and systems analysts in the development of sys- 
tems unique to their organization, rather than in redevelop- 
ing systems that have been developed by many before then. 
Additionally, if an organization deals with a reliable ven- 


dor, they minimize the risk associated with maintaining the 
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system. The organization's options are broadened in that if 
they do not have the skills or personnel available to main- 
tain the system, they may call upon the assistance of the 
vendor {at the established rate). 

There are a great number of software packages available 
that are marketed as aids to project management and control. 
These packages vary greatly in their scope. Some are 
designed to assist in the planning and tracking of only one 
project, others will handle any number of projects and pro- 
vide a great deal of flexibility within the organization. 
The problem is that there are very few written in FORTRAN, 
the preferred language for implementation at FNOC. 

The author found 3 packages that were available in 
FORTRAN. All 3 were eliminated fram cornsiceration because it 
was felt that they would not meet the minimum requirements. 

PAC I is marketed by International Sysytems Inc. (ISI), 
King of Prussia, Pa. This package is designed to track 
only 1 projeqt at a time and therefore was eliminated. 
P.D.FP.-E.D.M.S. is available from Centrol Data Corpora- 
tion. This package was eliminated due to its strictly 
financial orientation. 

OSCAR, marketed by On-Line Systems, Pittsburgh, PA., is 


available only in the time sharing mode. 
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Faizing to find a suitable FORTRAN software package, the 
author chose to continue the search under the assumption 
that it was stili feasible to purchase a software package 
and lease a COBOL compiler for less cost than in-house 
development. This idea will be discussed further in chapter 8. 

An examination of the trends and the state of the art in 
computer programming and software package applications, 
along with a preliminary analysis of the information 
reguirements of a project information and control systen 
(PICS) at FNOC, provided a background for establishing the 
criteria for selecting a computer software package. Woo- 
dridge, [Ref. 17] suggested 4 categories for software selec- 
tion criteria. These criteria address requirements in the 
area of features, technical and operational environment, 
implementation, and price of the package. The author used 
these 4 categories in the evaluation of the available 


packages. 


A. EVALUATION CRITERIA USED 


Ak, Features 





The package should contain as many of the features 


described in chapter 6, section B as possible. 
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2. Yechnical And Operational 


It must be possible to operate the package in the 
present environment. A thorough analysis of the technical 
and operational features of the candidate packages as they 
relate to the intended environment will assist in an appro- 
priate package selection. 

a. Hardware Configuration 

The package must be capable of operating on the 
equipment currently available. This includes the available 
core memory as well as peripheral equipment (ie. card 
reader, plotter, printer, etc.) Mainframes currently at 
FNOC availabie include 3 CDC 6500s, a CYBER 175, a CYBER 
203, a CYBER 170/720, and 2 PDP 11s. 

b. Higher Level Language 

A higher level language such as FORTRAN or COBOL 
must have been used to write the programs. 

Cc. Operating Systen 

The package should be capable of operating under 
the NOS/BE operating system. 

d. Ease Of Use 

The package must require minimal manual inputs. 
In other pedssuiit should be no more cumbersome than current 
manual reporting , record keeping, and aoe mechanisms at 


FNOC, 
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e. Flexibility 
incorporate selected current procedures and 
reporting formats. 
3. Implementation And Maitenanee 
Two necessary reguirements which ensure that the 
package can be implemented when needed and maintained with 
Minimal effort are: 
a. Immediate Availability 
package must be available for immediate delivery 
and implementation, not in an under development status. 
b. Supplier's Reputation And Business Integrity 
The supplier must be responsive to it user's 
problems. They must be a well established company with a 
Stable professional staff. 
c. Training And Documentation 
Documentation should cover the system, opera- 
tions, users, data preparation,and programming. It should 
allow for ease of use and maintenance. Training should be 
availablae and a training manual available for inspection. 
4. Price 
Ideally, the package should be available to the 
user with no additional start-up costs. 
Software directories and professional publications were 


searched to identify feasible candidate packages. 


31 





Many were eliminated immediately because they were not capa- 
ble of running on CDC equipment. The following packages 
were thought to possess most of the desired capabilities and 


Warrant closer review and examination by FNOC professionals. 


Pen tORNATIONAL SYSTEMS PAC II { Ref. 18] 
1. General Information 

International systems Inc. (ISI), King of Prussia, 
PA, has developed a sotware package for project management 
called PAC If. ISI specializes in automated project manage- 
ment systems. Pac II performs numerous and varied functions 
as depicted in Figure 8. 

Pac II is a totally data base oriented system, con- 
Sisting of 2 main modules. The planning module uses a sSin- 
gle, easy to use input sheet. This module assists the user 
in directing and scheduling project resources. It supports 
meommudiator capability with critical path identificiation, 
resource loading, and inter-project dependencies. Activi- 
ties can be assigned to resources by skill, as well as by 
specific resource identification. In fact, PAC II is capable 
of making proficiency level distinctions. 

The management module accumulates project progress 
information and makes available multi-level status, cost, 
and history information. A single turnaround document, 


which is designed by the user, feeds in the only information 
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PAC II FUNCTIONS 


: | 
| | 
| *budgeting *resource tracking | 
*planning *Progress reporting 
| *project simulation *automatic audit trail | 

*critical path analysis *status accounting | 
*scheduling *project monitoring | 
*nodelling *cost accounting | 
*skill scheduling *statistical analysis 
| *on line/real time *graphics | 
| Figure 8 


— 


necessary to report progress. The outstanding feature of 
this module is its ability to alert management early when 
problems occur. The user sets tolerance levels and the 
updated data base is constantly monitored. Should any of 
these limitations be broken, PAC II automatically alerts 
management and produces detailed reports for analysis and 
corrective action. (le. projects more than x months late or 
cost overruns greater than x percent) This is a particularly 
desirable feature. Project managers are understandably very 
reluctant to admit their project is behind schedule. This 
automatic reporting facility alerts upper management of this 


type of problen. 
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Although not explicitly termed milestones, the same 
function can be performed by defining what the PAC II sys- 
tem refers to as "EVENTS". The PAC II system can be used 
to plan a single project or any combination of projects, Any 
mumber of activities or tasks with dependencies across pro- 
ject lines. 

PAC II offers a variety of input methods: computer 
generated turnaround document, manual input forms, punched 
cards, terminal entry, or OCR. Table entries are used for 
those items of information that are placed on the file once 
only; but are used constantly (ie. skill codes, holiday 
schedule) . Use of table entries can save the user many 
repetitive entries and provides for ease of maintenance and 
modification. 

ISI offers a seperate add on option, the PAC II 
Report Writer, a facility for accessing the data base and 
producing reports that have not already been programmed into 
the system. This facility allows the user to request 
reports in a format they specify. Inputs are made via sin- 
ple English Language statements. ISI also offers an inter- 
active package which provides a terminal data entry and 
planning capability and a graphics package which offers 


users 2 different options: plotter or printer. These 
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optional software packages as well as the Report Writer 
Option, may be purchased with the basic PAC II system or be 
added on at a later date if desired. 
gee Gost Information 
Prices in effect as of the writing of this thesis 


are as follows: 


buy lease/purchase 
PAC II basic systen $26,000 $15,600/yr 
plus 1 time installation $2,160 
total $26,000 $17,760 
cost to purchase after 
One yeac $13,568 
optional software available 
PAC REPORT WRITER $4,000 $2,400 /yr 
plus 1 time charge $ 330 
total (1 year) S25 700 
PAC INTERACTIVE $10,000 $ 6,000/yr 
plus 1 time charge $ 830 
total (1 year) $6,830 





*70% of the first oe lease payment and installation 
charge will be applied to reduce the purchase price. 
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Basic package price includes: 


PAC If COBOL source programs (on tape) 
PAC II maintenance and enhancements for 1 year 
pre installation meeting 


documentation |. 

* implementation guide fe) 
coordinators case study $1) 
users reference manual ) 
project leaders guide (2) 
input forms 
user reference cards (39) 
selection of turnaround documents 


Hit tt HH 


installation, checkout, classes and OJT. 


3. Additional Information 

PAC II is currently installed on CDC eguipment in 
several areas. Contact was made with MS. Dee Thorne in the 
data processing department of Reynolds Electric and Engi- 
neering, Las Vegas, Nevada [{Ref. 19]. This company was cho- 
sen because it not only has a PAC II package installed on 
CDC equipment; but it is also operating under the NOS/BE 
operating system. This organization has a CDC 6400 and a 
CYBER 74 operating in tandem. Reynolds is the prime con- 
tractor for the Nevada Test Site and as such, they utilize 
PAC II in a variety of applications, including R&D develop- 
ment. 

Ms. Thorne indicated that they have received excel- 
lent response from ISI and that they are please with PAC II. 
They also purchased the PAC II REPORT WRITER option; but 


chose to develope their own interactive capability in-house. 
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Ms. Thorne is very agreeable to further consultation with 


FNOC staff. 


C. NICHOLS' N5500 (Ref. 20] 


1. General Information 





In 1977 Nichols and company of Los Angeles, CA., 
developed a project planning and control system, currently 
marketed as N5500. PERT and precedence networking enable 
the Nichols system to constantly monitor the impact of slip- 
pages and plan changes on in-process projects. What-if 
Simulation capabilities highlight the impact that proposed 
projects and/or changes will have on the current in-process 
work load. Critical path analysis and slack time indica- 
tions provide the user the ability to optimize schedules 
and minimize resource waste. 

The planning process starts with the user's defini- 
tion of the organization's planning environment. This is 
accomplished through the use of a dictionary mechanisa. 
This means this information need only be inputed once. the 
dictionary is maintained seperately from the rest of the 
data which makes validation and modification a less compli- 
cated task. The use of the dictionary also allows the sys- 
tem to be adapted to any life cycle ened: work 


breakdown structure, or documentation standards. The use of 


2) 





the dictionary mechanism also significantly reduces the 
redundant entry of data. This means a time and effort 
savings to the user. 

The Nichols system, like the PAC II system, has an 
option for automatic assignment of resources by the systen, 
which can be valuable to the planner. Ckanges to projects 
can be accomplished with remarkable ease. Tasks may be 
added, changed, or deleted at any time, and the impact of 
any change will automatically be shown on all related tasks 
and projects. Task changes only require that a project nun- 
ber, task number, and the revised data be entered. 

Project control is accomplished through the distri- 
bution of work schedule reports use to publish work assign- 
ments. Each person or group then reports back the work done 
on each task during the week, the work remaining to be done 
on each in-process task for that week, and any comments they 
Wish to call to the project managers attention. 

[The Nichols system has a mechanism where-by an overt error 
in a data field will not cause the system to stop perforn- 
ing. The system simply makes a best guess and executes the 
program regardless of the number or severity of these 

errors. Although these errors are flagged and continue to 
be flagged until corretted; this feature should be closely 


examined by FNOC analysts to determine if it is desirable. 
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[The Nichols system offers 20 report formats as part 
of its basic system. These reports cover 6 major groupings: 
administration, project planning and control, resource load 
and distribution, history and committment of resources, per- 
formance analysis, and accounting. One output file inter- 
faces with a plotter to provide critical path analysis. 
Other reports are in either tabular or graphical form and 
acre easily read and interpreted. The Nichols system also 
offers an optional generalized REPORT WRITER add on to allow 
the user to design their own reports. 

The weakness in the Nichols reporting structure lies 
in the fact that they measure progress via percent completed 
rather than milestones completed which can be very mislead- 
ing. The variance indicators are a key attraction, drawing 
Managements attention to areas that are off target. 


2. Cost Information 
Prices in effect as of the writing of this thesis 


are as follows: 


BOY Lease/Purchase 
N5500 Basic System $25,000 $15,000/yr 
plus 1 years maintenance - n/a $ 1,000/yr 
total (1 year) $16, 000 
Cost to purchase after 
i year : es n/a $11,500 


OPTIONAL SOPTWARE AVAILABLE (not available as lease) 
REPORT WRITER $ 5,000 
Interactive $10,000 
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Package price includes: 


object code (source will be delivered on tape upon receipt of 
payment 


technical documentation (1) 
user manuals (5) 

> days of on site training 
input forms 


1 year maintenance with purchase 
3, Additional Information 

Tektronics, a production facility that among other 
things produces terminals. N5500 was originally installed 
on a CYBER 73; but due to work load constraints, they 
Switched to their CYBER 175. This action resuited in faster 
turnaround time. The operating system being utilized is NOS 
level 509. 

Contact was made with Ms. Charlene Madiman, who is 
the data base administrator for the Product Safety Division. 
(Ref. 21] She is responsible for data entry and interpreta- 
tion in support of the N5500 applications. Ms. Madiman 
indicated that they were very pleased with the N5500 pack- 
age. Their input is done via terminal and then batched into 
the system for processing. All data entry and interpreta- 
tion is done by Ms. Madiman and she says this is a full tine 
job considering the number of projects/instruments she works 
With (over 350). Inputs from project eee: is very 


straight forward and involves entries on a pre-printed forn. 
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Only two negative aspects were reported. First, that the 
previous version of the user manual was difficult to inter- 
pret.* The second problem area was in the error handling 
mechanism. Errors are flagged and continue to be flagged 
until corrected; however there is no indication as to the 
type of error. Error correction may prove to be very time 
consuming if the error is not readily apparent. 

Ms. Madiman indicated that their staff would be 
happy to discuss the package and its implementation further 
with PNOD staff.** Ms. Cindy Wong, marketing representative 
for Nichols, has indicated that there is a good chance that 
N5500 will be converted to NOS/BE for another customer in 


the near future [{Ref. 22]. 


D. MSP*s PROJECTMANAGER [Ref. 23] 
1. General Information 
PROJECTMANAGER was market2d originally in 1972 under 
the name PMACS. It is a batch processing system which main- 
tains 3 major files: the resource file, the activity file, 


and the project files. Generally, the resource file and the 


activity file need only be set up once. The project file 





*Nichols has released a new version of the user manual; 
however 4s. Madiman has not used it long enough to evaluate 
ot . 


Bee Se? ts oint 1s nts Goltz, manager of software 


Iman 
Support, at 3) 627-4675. 
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activity file need only be set up once. The project file 
contains the project plan, estimates, progress to date, and 
new projects as reguired. Projects can be broken down into 
subproject levels called tasks. 

PROJECTMANAGER requires periodic updating of work 
accomplished and costs incurred. The user selects the 
reporting period. Mandatory entries are resource, project, 
and activity codes. Optional entries include task, rate of 
pay, computer use codes as well as various expence catego- 
ries and projection data items. 

Input can be by card, or card image on magnetic 
media, paper tape, or on-line data entry. All input tran- 
sactions are read into the system by a data validation pro- 
gram, which carries out exhaustive validation of each input 
record and messcts any erroneous data. A report is produced 
by the program so that alli detected errors are clearly 
described to the user for correction and resubmission. 

PROJ ECTMANAGER output consists of 3 main types: 
validation reports, file content listings, and user selected 
progress reports. 

Validation reports are produced whenever data is entered. 
All input information be printed including error codes and 


pointers that identify incorrect items. 
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File content listings are obtained on demand in standard 
format and are of particular interest to those who control 
code allocation and related tasks. 

Progress reports can customize the system to the needs of 
the organization. The number and type of the output 
reports is determined by the user. 


2. Cost Information 





The PROJECTMANAGER package can be purchased for 
$8,000. The package includes: 
Object code {on tape) 


1 days on-site training and advise 
1 set of documentation 


3. Additional Information 


Because of the relatively low cost, this package was 
included for consideration, even though it has not been 
implemented on CDC equipment and will require some in-house 
Sort. The package was written in COBOL for IBM equiment; 
but has been coverted to operate on Burroughs, Honeywell, 
and ICL equipement. A recent conversion from IBM to ICL 
DME/V took one user group 17 days. Larry Hagg, West Coast 
Region Manager fo MSP, has indicated that PNOC could obtain 
the source program at no additional charge, if they wished 


to convert the package themselves. [Ref. 24] The code should 
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be examined closely by FNOC analysts to determine if there 
would be any problem in conversion. Generally speaking, 
conversion of COBOL programs is relatively easy. The prob- 
lem is that once FNOC makes this conversion, MSP will not be 


able to provide the maintenance. 


E. OTHER PACKAGES EXAMINED 

Other packages examined and subsequently eliminated are 
included here to assist FNOC in acquisition in the event 
that they choose to follow through on a PICS. QUICK TROL, 
marketed by Quality Data Products Inc., is written in 
assembly language and can not be adapted to CDC equipment. 
PROJECT MONITOR, Marketed by Program Products Inc, was 
unresponsive to requests for additional information. Infor- 
mation on PC 70, marketed by Atlantic Software Inc., was 
received to late to include in this analysis. It is recon- 
mended; however that should FNOC consider the purchase of a 
software package, Atlantic Software Inc. Be given an invita- 


mon for bid. 
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VIII. ALTERNATIVE COURSES OF ACTION 





A. MANUAL ALTERNATIVES 

The alternatives requiring the least time, effort, and 
resources are those that require little change to current 
methods; however these alternatives may not be the nost 
desirable, Two manual alternatives are presented here 
because they are considered viable alternatives. 
ALTERNATIVE 1: CONTINUE AS IS 

The obvious advantage to this alternative is that it 
requires no effort and no cost. That is, no direct cost. 
It could cost in terms of the efficiency and effectiveness 
of the organization. With the exception of the work unit 
reporting, which is done twice a year, there is no formally 
defined reporting structure for project management at FNOC. 
Formal reporting permits ready comparison of progress with 
plans and ensures a uniformity and consistency of informa- 
tion throughout the project. It also provides a historical 
record of the project. Failure to keep adequate well struc- 
tured reports makes it very difficult when others are forced 
to assume management duties. Personnel turnover at FNOC is 


high due to the military environment. It:‘is therefore 
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critical that records allow the new project manager to trace 
what has been done and what remains to be done in the pro- 
ject. Many projects span several years, so the chance of 
turnover in project personnel is high. Use of civilians in 
k2y positions eases this problem somewhat; but does not eli- 
Minate it all together. 

With no compiete historical records of projects, FNOC 
Will find great difficulty in presenting and defending their 
actions in case of contract dispute and litigation. Histor- 
ical records of a project can also assist the project man- 
ager in planning future projects and hopefully, in avoiding 
mistakes made in prior projects. 

ALTERNATIVE 2: ENHANCED MANUAL SYSTEM 

Enhancement of the current manual system could serve to 
alleviate some of the problems noted previosly. This 
enhancement can take the form of in-house establishment of 
definitions and procedures or perhaps the purchase of a pro- 
ject management methodology. 

In-house enhancement means those who establish the meth- 
odology will be intimately familar with the FNOC environ- 
ment; however they may not have the project management 
expertise that might be available on the outside. Staff 


time will still be required to determine amd put into effect 
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the methodology. This may be time that could be better 
spent elsewhere. 

There are several methodologies marketed that would pro- 
vide assistance in establishment of a project management and 
control system. Spectrum, marketed by Spectrum Interna- 
tional Inc. of Los Angeles,CA., and SDM/70, marketed by 
Atlantic Software Inc. of Philadelphia, PA., are two such 
methodologies. Eee oes price ranges from $32,000. Price 
2s dependent on the number of programmers and analysts that 
must be trained. For a staff of 40-50, the price goes up to 
$50,000 , which includes the 16 days of training. The 
SDM/70 price of $30,000 includes training and the availabil- 
ity of a 24 hour hot line. These prices are relatively high 
in comparison to the automated packages available. They 
also fail to eliminate a key problem, relating to timeliness 
and accuracy of reports. The amount of correlation and 
calculations needed to produce some reports preclude the uss 
of manual methods. Speed and accuracy are vital parts of 
progress reporting and are primary benefits accorded by a 


computer. 


B. AUTOMATED ALTERNATIVES 
Projects involve the deployment of a number of person- 


nel, equipment, and money, and the integration of activities 
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to achieve some predeternined aim. This means that these 
activities must have been pre-planned, and the degree of 
Success achieved depends to a large extent on the effective- 
ness of the planning. There are many types of projects and 
activities that do not lend themselves to manual control 
methods, for example, those that involve a large number of 
Organizations or people. Additionally, the interdependen- 
cles of the various parts of the plan may be to complex for 
an individual to monitor and traditional methods of repre- 
sentation (ie. bar charts or schedules) may not represent 
the plan effectively. Finally, the project may span long 
lengths of time, making it difficult to track manually. 
With these points in mind, it becomes necessary to consider 
alternatives that provide for some means of automated assis- 
tance for PICS. The following alternatives provide that 
capability. 
ALTERNATIVE 3: IN-HOUSE DEVELOPMENT 

There are several advantages to in-house development. 
First, the system must be acceptable within the user envi- 
ronment and to the user group. By developing it in-house 
there is a greater opportunity for user involvement. The 
user must identify the new system with their operational 


requirements from the start, this too is made more viable by 
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in-house development. Change needs to be self-motiviated if 
it is to be successful and long lasting. The organization 
must take the responsibility for and be committed to the new 
progran. 

In-house system development is rarely cost-effective 
when compared with outside purchase. Valuable system usage 
time is lost while the in-house system is developed. Due to 
the developmental nature, there is a degree of uncertainty 
as to the cost and schedule completion. Additionally, staff 
must be allocated to the development, who may be utilized 
more effectively on organization specific development (ie. 
oceanographic and/or meterological products). The mainte- 
nance/fenhancement cost of in-house software is normally in 
the region of 50% of the original cost per year. While it 
is true that in-house systems may be geared more closely to 
the original requirements; this may make them less flexible 
when ammendments become necessary. 

ALTERNATIVE 4: PURCHASE SOFTWARE PACKAGE 

It would be advantageous to puchase a software package 
rather than suffer the expense and time delay that would be 
necessary to design and program a PICS specifically for FNOC 
applications. Beeause the vendor is able to spread his 


package development costs across a number of installations; 
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it represents a real discount on the investment reguired for 
a Similar development in-house. Funds can be budgeted and 
an installation date scheduled with a great deal more cer- 
tainty. The organization also gains the value of the ven- 
fons project management expertisa and the experience gained 
by installations at other sites. Additionally, many of the 
software bugs will have been corrected. The problem is that 
the organization may not be as receptive to a package that 
will change their methods. It will be important to make the 
transition as painless as possible. Many of the packages 
allow the user to define terms and establish procedures con- 
sistent with those currently in use. The organization must 
assure that documentation is complete since they may be 
required to maintain it or puchase maintenance services from 
the vendor at additional costs. 

Purchase of a software package will probably reguire 
purchase/lease of a COBOL compiler since very few packages 
are written in FORTRAN. Contact was made with Mr. Ken Gat- 
liffe, local CDC representativ2, concerning pricing informa- 
tion. A COBOL compiler for a CYBER 170, 175 or CDC 6600 
would cost $12,540 to purchase or may be leased for $310 a 


month plus a one time fee of $140 [Ref. 25]. 
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ALTERNATIVE 5: REVIVE OLD SIS 

The FNOC MIS system was originally designed for use by 
one department head and later adopted for command-wide use. 
It was not designed with the organizations overall objec- 
tives in mind. It was designed to fill a particular need at 
that time. The designer of the program and those that had 
been directly involved in its operation, have long since 
departed FNOC. Documentation is not complete and therefore 
revision and/or updating will not be an easy task. It will 
take a great deal of time for someone to become familar 
enough with the code to start to adapt it. Additionally, 
there are still some very negative attitudes remaining con- 
cerning this MIS . It was never well defined, inputs and 
updates were erratic, and the system only received sporadic 
attention by upper management. Not only did middie manag- 
ers, who were required to submit the update information, not 
derive any benefits from the system; but they saw that upper 
Management was not utilizing it. They saw their efforts as 
wasted, and when they did see any outputs from the system it 
Was not current information. 

This system reguired at least 1 fuil time administrator, 
although 2 would be nore realistic considering the amount of 


data entry required. If the documentation were clear enough 
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and only minor changes were needed, this would clearly be 
an economical approach. The ramifications of the staff atti- 
tude problem is indeed difficult to predict. 

ALTERNATIVE 6: DEDICATED MINI 

Initially this alternative will be the most costly. Not 
only will the organization need to purchase the computer; 
they will also have to purchase or develop the software 
package. This alternative will, in all liklihood, take more 
time from decision to installation than the others. It will 
also require the involvement of more FNOC technical person- 
nel in the acguisition, due to the hardware. 

This alternative has several distinct advantages. Hav- 
ne a dedicated or semi-dedicated mini makes access easier 
and allows for continued operations when the main computer 
system goes down or is over loaded. It also allows the pos- 
Sibility of a wider selection of software packages. Greater 
benefits may be derived by utilizing the mini for other man- 
agement and/or administrative applications, such as an 
inventory control system, electronic mail, etc. It also 
would open up a wider range of possible software packages 


for this and other applications. 
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IX. CONCLUSTON AND RECOMMENDATIONS 


Project Managers are responsible for planning ideeenes 
duling various projects and assignments. They must face 
changing priorities and resources and respond appropriately. 
Changes and reevaluation of projects involving new priori- 
ties, resource availability (or lack of availability), new 
dependencies, ect. make management of on going projects a 
full time job. 

A highly complex and expensive undertaking like a soft- 
ware development project requires careful planning. The 
project manager can not hope to schedule, measure, and con- 
trol. complex programming activity without a formalized, 
highly developed plan. All projects need planning. In most 
cases this involves a detaiied breakdown of all the tasks 
which make up a project to ensure that realistic schedules 
of anticipated progress can be prepared. Each task needs to 
be of an easily identifiable and self contained nature so 
that measurement of progress is made as simple as possible. 
Within each tasK self contained check points must be estab- 
lished so that comparison of actual progress against planned 


progress can be made at meaningful intervals. 
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The only realistic way to be in control is to see regu- 
lar evidence of progress (evidence of tasks/jobs completed). 
Documents to control projects must take into account a 
balance between the need for control; and the desire to keep 
form filling to a minimun. 

One ef the more important features of the project con- 
trol system is the method of reporting. It should serve to 
formalize the kind of casual reporting that occurs in all 
organizations. Formal reporting permits ready comparison of 
progress with plans and ensures a uniformity and consistency 
of information throughout the project. 

It 1S the author's opinion that FNOC needs a better 
defined and more uniform project information and control 
System. The current formal reporting mechanism and the 
informal reporting to the commanding officer, are neither 
adequate nor efficient. Verbal reports to the commanding 
officer are time consuming and may not be the best presenta- 
tion mode. Presentation of one project without a view of 
how it fits into the overall project environment may give a 
distorted picture. Use of the word processor for anything 
other than processing textual information is not authorized, 
therefore correlation of information must be accomplished in 


some other manner (Ref. 26 & 27}. 
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It is also the author's opinion that correlation and 
presentation of project information can best be accomplished 
by an automated PICS. 

Based on information obtained in the preliminary analy- 
Sis, the author's preference is for the PAC II software 
package. This is based primarily on 2 findings. First, the 
fact that this system has been implemented successfully on 
CDC equipment and the same operating system as utilized at 
FNOC. Additionally, this package appears to be flexible 
enough to meet current and possible fututre needs of FNOC. 

Although it is the author's opinion that adoption of an 
automated project information and control system at FNOC is 
a desirable action; and that this action if properly imple- 
mented will enhance FNOC's effectiveness and efficiency; the 
following must serve to qualify this recommendation. 

The first and primary consideration for implementation 
is that top level management at FNOC must make the decision 
to give full and active support to such a system. Without 
this support the system has very little chance for success. 
Positive action must be taken if requirements are not met by 
principle investigators and project managers. A steering 
committee, whose primary function is to review procedures 


and assure compliance, might be considered. 
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Once the decision is made to provide this support, an 
evaluation group, composed of programmers, analysts, project 
Managers and principle investigators, should be formed. The 
Executive Officer and/or the Commanding Officer may also 
wish to be a part of this group since they are also users. 
Acquisition must go out for competitve bid unless sole 
source can be justified, which is unlikely in this case. 
Distributors of all packages reviewed offered demonstrations 
and/or presentaions of their package capabilities. It may 
be appropriate to allow vendors to make a presentation prior 
to the decision to automate. It would certainly serve to 
provide visual proof of what an automated system can and can 
not do. 

Once a package is selected; it is recommened that in 
order to minimize the disruption, FNOC not convert in-pro- 
cess projects to the new system. It would be best to start 
only new projects on the new system. This will minimize the 
burden on the staff and management personnel and allow for a 
smoother transition. 

The development and implementation of a project control 
system is, in itself a project. A great deal of extra 
effort is needed. Just how detailed any project control 


system becomes is a function of the system size and 
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complexity of the organization in which it is being applied. 
Generally, whatever the effort, the cost of a typical soft- 


ware development project is reason enough to justify it. 
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APPENDIX A 
Requirements Checklist 


ENERAL INFORMATION 


This checklist is part of a study being conducted on pro- 
ject management and control at FNOC. The information on the 
following pages was acquired as a result of interviews con- 
ducted with a select group of key FNOC project personnel. 
The question posed was; what information requirements and/or 
Capabilities would you like to see in a project management 


and control system at FNOC (either automated or manual). 


The requirements listed on the following pages represent 
ONLY those that were mentioned during the personal inter- 
views. The list, in all probability, does not cover all pos- 


Sible requirements. It is; however, a starting point. 


The requirements have been grouped according to six 
general functional categories to facilitate an orderly 
presentation mode. This categorization was based strictly on 
the subjective judgement of the interviewer. Some of the 
requirements could very well fit into more than one of the 
categories; however they are listed only once for 


Simplicity. 
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DIRECTIONS 


Your cooperation is requested in reviewing and responding 
to the checklist items on the following pages. Each iten 
requires two checks; one in response to whether or not 
you'll use the information and one in regards to how you 


would prefer it to be stored. 


If after reviewing these reguirements you can add to the 


list please do so; your input will be a valuable addition. 
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